home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 6960 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.9 KB  |  79 lines
  1. Path: haapa.oulu.fi!not-for-mail
  2. From: tikarjal@haapa.oulu.fi (Timo Karjalainen)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Q: Finding ASL Window ptr
  5. Date: 6 Apr 1996 14:02:13 GMT
  6. Organization: University of Oulu
  7. Message-ID: <4k5th5$4tt@ousrvr3.oulu.fi>
  8. NNTP-Posting-Host: haapa.oulu.fi
  9. Mime-Version: 1.0
  10. Content-Type: text/plain; charset=iso-8859-1
  11. Content-Transfer-Encoding: 8bit
  12. Summary: How to find the Window address of an open ASL req?
  13. Keywords: ASL, Window, IDCMP, stupid trick with the OS
  14. X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
  15.  
  16. Some time ago I wondered how to get an ASL requester closed
  17. without user intervention. One proposed solution was to send
  18. the ASL requester window a fake IntuiMessage IDCMP_CLOSEWINDOW.
  19.  
  20. Now: How do I find this Window, and thus its UserPort? I'll need
  21. that in order to put a Message there. :-D 
  22.  
  23. It would be most convenient if the ASL structure had a field in
  24. it that would contain the address of the Window. This is, however, 
  25. not the case. (Well, its really ASL private information, but hey, I
  26. *need* to get that thing closed somehow!) 
  27.  
  28. My program runs on a private screen. I know the addresses of all 
  29. open windows that are my own. Do I just have to step through the screen's
  30. Window list and send a faked IDCMP_CLOSEWINDOW to all windows whose
  31. address I do not have in the list of "known windows"? Is this even
  32. legal? struct Screen has a documented Window ptr and struct Window has
  33. a documented next Window ptr. 
  34.  
  35. Hey, Amiga Tech, if you're reading this: I hope you'll fix the VERY BROKEN
  36. ASL feature of IntuiMessage callbacks. For a program to do one-task
  37. multiwindowing with more than one window handling user input at a time,
  38. it really needs to do asynchronous ASL requesters! However, AslRequest()
  39. only returns after the user is finished with the requester. If the only
  40. way to process user input while in AslRequest() is to use the shared IDCMP
  41. & callback feature, there must be a way to close an open ASL requester!
  42. I really suggest you add to asl.library a function CloseAslRequest(), which 
  43. would take the address of an ASL requester structure and close the requester,
  44. if it was open.
  45.  
  46. A better solution would be an AsynchAslRequest(). It would open and set
  47. up the requester window and *return immediately*. Once the program notices
  48. an IDCMP message that is for an ASL requester, it would pass the message
  49. to an asl.library function that would process it. This function would return
  50. NULL if the IDCMP event didn't lead to closing the requester, otherwise
  51. it would return the address of the ASL requester structure.
  52.  
  53. In fact it would be best to have a CloseAslRequest() as well, and also 
  54. something to ReopenAslRequest(). Sometimes a program needs to close the
  55. ASL requester while it for example closes the screen and reopens it in
  56. another display mode. Reopening would bring the requester back just like
  57. it was never closed, except that it would take into account possible 
  58. changes in the screen, like another font and adjusting requester size 
  59. or position if the screen has become smaller. 
  60.  
  61. Additions like these are *necessary* for Amiga applications to be
  62. consistently what Amiga is best known for: multitasking. With these 
  63. things done, Amiga applications could maintain full "internal multitasking"
  64. capabilities and intuitiveness. Didn't the Style Guide say that quitting
  65. a program should be possible at all times and that the user should be 
  66. given all power to do anything?áWell, ASL makes those things impossible.
  67.  
  68. I think I'm not the only one who *just hates* file or other requesters that
  69. disable them from doing anything else. Sometimes you *need* to able to do
  70. something else while the requester is open. Once you can do a little 
  71. something, you'd expect you can do *anything* - also things like quitting
  72. the program or changing (closing!) the screen on which the requester has
  73. been opened. It's a matter of user-friendliness. It isn't very fun to chase
  74. down every single requester window on a crowded screen. 
  75.  
  76. tikarjal
  77.  
  78.  
  79.